1. Field of the Invention
The present invention relates to a method, apparatus, and computer readable storage for dynamically maintaining and executing data definitions and business rules in an electronic procurement system. More specifically, the present invention relates to a method, apparatus, and computer readable storage which allows a plurality of users to easily create, modify and dynamically maintain their business rules and data definitions for use with an electronic procurement (“e-procurement”) system, without requiring outside intervention for such tasks as recompiling. The present invention further allows an electronic procurement system to be capable of integrating with multiple application systems.
2. Description of the Related Art
E-procurement systems allow an entity to conduct transactions such as browsing for, selecting, approving, and actually purchasing goods from a supplier. The entity can typically be a department of the government, private business structure, or any other type of organization or entity that purchases goods. For example, the entity can represent a government agency or business, departments within the government agency or business, or even individual buyers.
When, for example, a government agency arranges to make a purchase, typically there are individual approvers and/or a chain of approvers that have to approve the purchase. If the government agency decides to purchase a new computer monitor, a person in charge of computer equipment may have to individually approve the purchase. This is considered a business rule. In addition, if the purchase exceeds a first preset amount of money, then a first financial officer may have to approve the purchase. If the purchase exceeds a second preset amount of money, then a second financial officer may also have to approve the purchase, after the first financial officer approves. This “approval chain” of the first and second financial officers represents the “workflow” for the government agency. Workflow is a type of business rule, although a business rule may not be considered a workflow if it does not contain an approval chain.
Another type of business rule used by e-procurement systems is a default field for users. In a typical e-procurement system, default codes, such as accounting codes, are maintained by a system administrator. One example of an accounting code can be, for example, a bank account number. A particular user of an e-procurement system may need to draw from a particular bank account number, and of course it is advantageous to the user if this particular bank account number is automatically used for each purchase. Having accounting codes stored and automatically used for transactions reduces errors, and having the correct codes is crucial if transactions are to be sent to and accepted by other systems. For a large organization (for example the government), the work needed to accurately maintain proper defaults for thousands of users can become prohibitive.
Further, some departments (or even individual users) within an organization may require different defaults (or business rules). For example, different users from the same organization could use different fund codes for computer purchases and require different defaults. Another example is certain users may want to do a pre-encumbrance (reserving of funds before a purchase), while other users may not. These types of business rules typically require a great deal of customization for each unique situation.
E-procurement systems often need to integrate with external application systems such as financial system, inventory systems or enterprise resource planning (ERP) systems. When an e-procurement system needs to interact with an external system, the prior art requires that a custom program be written to implement data communication between the e-procurement system and the application system.
Sometimes, specific data required by the application system is not available in the e-procurement system. Also, there can be fields that users desire to store that are not available for storage on the particular e-procurement system being used, for example fields directed to reporting purposes but not used in any way by the e-procurement system.
When a government or private entity is set up to make purchases using an electronic procurement system, business rules can/or user specific data fields need to be programmed into the electronic procurement system in order for the business rules and/or data fields to be implemented electronically. Typically, the programming of the business rules and/or data fields is accomplished by having to call technicians from the manufacturer of the electronic procurement system in order for them to program (or reprogram) the business rules and/or data fields. When the entity desires to change the business rules and/or data fields, the technicians are needed again to reprogram the business rules and/or data fields in the electronic procurement system. The reprogramming is typically carried about by modifying the source code used for implementing the, business rules and/or data fields and then recompiling the new source code. Thus the prior art business rules and/or data fields can be considered “hard-coded.” Another disadvantage to custom coding or hard-coding the business rules and/or data fields is that the electronic procurement system must be taken offline and be made unavailable during this process.
In addition to the problem of non-dynamic or customized hard-coded business rules and data fields, prior art electronic procurement systems also lack scalability. Typically, an electronic procurement system needs to interface with external systems in order to implement transactions such as electronic reservation of funds. However, prior art electronic procurement systems have difficulty interfacing with more than one external system. Interfacing with more than one external system requires extra system resources, for example extra hardware, and also may require modifications of the e-procurement system to handle different data fields. In addition, interfacing with multiple external systems requires multiple executables (an executable can be defined as a process running in memory) of the procurement system. Using multiple executables is not desirable in that it results in a more unreliable system as well as requires more resources. In addition, sharing of data may present a problem when running multiple executables.
FIG. 1A is a block diagram illustrating a simplified example of a typical electronic procurement system implementing business rules and workflow of the prior art.
Referring now to FIG. 1A, a buyer 1 104 communicates a purchase request to the e-procurement system 100 via a computer communications network 103 or communication line 103. The e-procurement system 100 includes business rules and workflow storage 101 for the buyer 104. The e-procurement system 100 also contains catalog storage 115 and a network engine 114. The network engine 114 is used to communicate with suppliers and receive catalog information, which in turn is stored in the catalog storage 115. Assuming that a particular purchase request by the buyer 1 104 requires approval from approver 1 106, the e-procurement system 100 sends an approval request to approver 1 106 via a communication line 105. The approval request is typically sent via e-mail, although any communication method, such as voice mail, paper mail, or even wireless transmission, can be used. Approver 1 106 sends his or her approval back to the e-procurement system 100 via the communication line 105.
If approver 1 did not approve the purchase request, then the e-procurement system 100 sends back a denial to buyer 1 104 via the communications line 103. Assuming approver 1 approves the purchase order, the e-procurement system 100 sends financial information regarding a purchase request to a financial system 1 112 via communication line 111 in order to arrange for securing the funds and arrange payment to the supplier.
The e-procurement system 100 also sends purchase information regarding the purchase request to a supplier 110 via a computer communications line 109. The purchase information typically includes information such as the items desired for purchase, quantity, etc. The financial system 1 112 sends payment information to the supplier 110 via a computer communication line 113, which can include electronic payment.
Similarly, buyer 2 109 also can make a purchase request to the same e-procurement system 100. Note however, that buyer 2 109 may have different business rules (and workflow) that buyer 2 109 must abide by (as opposed to other buyers using the e-procurement system 100 such as buyer 1 104). In the case of FIG. 1A, buyer 2 109 needs approval from approver 2 108, before the purchase request by buyer 2 109 is approved. Buyer 2 109 also requires interaction with financial system 1 112 via the e-procurement system 100 via communication line 111.
Note that buyer 1 104 and buyer 2 109 both belong to organization A 116, which requires interaction with financial system 1 122. An organization can be an entire business or government entity, a subset of an entity, or even a single person. In FIG. 1A, all members of organization A 116 who create transactions via the e-procurement system 100 require interaction with financial system 1 122.
Many financial or ERP systems exist. However, each such financial system requires a different database structure, communication protocol, or “handshake” for communicating with purchasing computers. If it was desired to integrate with a new financial system, the prior art afforded no easy and efficient way to achieve such an integration. In addition, different buyers may need to employ different sets of business rules and/or data fields. The prior art afforded no easy and efficient way to allow different buyers to have different business rules and/or data fields, while using the same electronic procurement system.
FIG. 1B is a diagram illustrating one approach the prior art uses to allow different buyers from different organizations, each organization requiring interaction with an e-procurement system and a different financial system and having a different set of business rules and/or data fields. The approach illustrated in FIG. 1B is a “dedicated system” or “unhosted model” approach, wherein an additional e-procurement system is used for each organization.
Referring now to FIG. 1B, buyer 1 118 belongs to organization A 117. Buyer 2 122 belongs to organization B 121. Organization A 117 requires interaction with financial system 1 120, while organization B 121 requires interaction with financial system 2 124. Note that this situation is in contrast to FIG. 1A, where both buyers interacted with the same financial system because they are from the same organization. Buyer 1 118 communicates with e-procurement system 1 119, which implements transactions with financial system 1 120. Similarly, buyer 2 122 communicates with e-procurement system 2 123, which implements transactions with financial system 2 124. Note that in FIG. 1B, buyer 1 118 and buyer 2 122 have different business rules and/or data fields associated with them.
The unhosted model implementation illustrated in FIG. 1B is disadvantageous in that an entire e-procurement system is dedicated to each organization. This can be a waste of resources in that each e-procurement system 119, 123, may not use all of its own resources. The resources used by both e-procurement system 1 119 and e-procurement system 2 123 may be small enough to run on only one e-procurement system, instead of two.
FIG. 1C is a diagram illustrating a “hosted” model. The e-procurement system 125 maintains multiple executables for each of buyer 1 127 and buyer 2 129. Typically, in the hosted model, each buyer would have a dedicated executable. A user's dedicated executable can interface with the proper financial system and execute the user's own business rules.
Referring now to FIG 1C, buyer 1 127 has executable 1 131 dedicated to processing transactions for buyer 1 127 and organization A 138. Executable 1 131 interfaces with financial system 1 135, using special routines written to properly communicate with financial system 1 135. Executable 1 131 also implements the business rules for buyer 1 127. Similarly, buyer 2 129 has executable 2 133 dedicated to processing transactions for buyer 2 129 and organization B 139. Executable 2 133 interfaces with financial system 2 137, using special routines written to properly communicate with financial system 2 137. Executable 2 133 also implements the business rules 2 129.
Thus, even though buyer 1 127 belongs to organization A 138 which requires financial system 1 135 and organization A's business rules, and buyer 2 129 belongs to organization B 139 which requires financial system 2 137 and organization B's business rules, both buyers can still share the same e-procurement system 125.
However, the problem with the configuration as illustrated in FIG. 1C is that assigning a dedicated executable for each buyer having unique characteristics is inefficient as far as resources are concerned. A typical e-procurement system can only run a limited number of executables at one time. Further, adding new financial systems is difficult because each new financial system has a different protocol that it requires. Therefore, cumbersome programming in the e-procurement system is required in order to accommodate different financial systems.
Furthermore, prior art e-procurement systems have difficulty interfacing with more than one external system. Different users may need to employ different business rules and/or different sets of data including different sets of fields and their respective values. Especially with the hosted model described above, the e-procurement system has to deal with users from multiple organizations which interact with multiple application systems, each user or organization requiring their own sets of data fields. It would not be efficient or cost-effective to customize an e-procurement system with hard coded business rules and/or data fields for each client organization or for each different application system.
Therefore, what is needed is an efficient, dynamic system that can dynamically maintain and execute business rules and/or data fields for an e-procurement system with multiple users, which require different business rules and/or data fields for interfacing with external systems. What is also needed is a scalable procurement system that can efficiently interface with multiple external systems, using one executable of the electronic procurement system.